|
|
|
|
Rozproszone systemy plików CODA
Co to są Rozproszone Systemy Plików?
- zachowują pliki na jednym lub wiecej komputerów (serwerów), i udostępniają je innym komputerom (klientom) jako
część ich drzewa katalogów
- większość emuluje system plików UNIX-a
- w większości stosowane jest buforowanie danych po stronie klienta (ze względu na wydajność)
- większość operacji (statystycznie) jest typu READ, mniej WRITE (i to przeważnie na rozłącznych plikach)
Zalety Rozproszonych Systemów Plików
- większa dostępność plików, łatwiejsza obsługa (niż np. przesyłanie kopii po sieci)
- łatwiej robić kopie zapasowe (backup'ujemy tylko serwery)
- możliwość udostepnienia "dysku o dużej pojemności" (w razie potrzeby dodajemy nowy serwer)
Problemy związane z przesyłaniem po sieci:
- obciązenie sieci (przesyłamy dużo albo duże pliki)
- przeciążenie serwera
- bezpieczeństwo (autoryzacja, "podsłuchanie" danych)
Przykłady Rozproszonych Systemów Plików:
- AFS - Andrew File System
- CODA (pochodzi od AFS)
- IBM DCE/DFS
- CIFS - Common Internet File System
- Windows DFS - kawałek specyfikacji CIFS, służy do organizacji dysków dzielonych
- Samba
Rzut oka na CODE (ogólny)
Co to jest CODA?
- zaawansowany sieciowy system plików
- powstał w 1987 w Carnegie Mellon University w USA
- oryginalnie zaprojektowany na Mach 2.6, przeniesiony na Linux, NetBSD,FreeBSD, Windows 95;
może będzie pod Windows NT
- pochodzi od systemu plików AFS
- główne powody powstania nowego systemu - spełnienie wymagań tzw. "stałej dostępności danych":
- szerszy dostęp do plików dzielonych
- większa tolerancja na uszkodzenia/wyłączenia serwerów
- obsługa urządzeń przenośnych (np. laptopów) - pliki potrzebne użytkownikowi do
kontynuowania pracy powinny być dostępne po odłączeniu od sieci
Zalety CODA
- wsparcie dla urządzeń mobilnych (operacje odłączone) : reintegracja danych od odłączonych
klientów, adaptacja do @@szerokości łącza
- wysoka wydajność : zastosowanie pamięci podręcznej po stronie klienta
- odporność na awarie : serwery replikacyjne, rozwiązywanie konfliktów serwer/serwer
- większa przepustowość i dostępność : zwielokrotnione wolumeny
- bezpieczeństwo
- dostęp do kodu źródłowego
Klika charakterystycznych cech
- podłączenie jest do "Cody" a nie do indywidualnych serwerów (w przeciwieństwie do NFS)
- standartowo mountowany pod /coda jako typ "Coda", wszyscy klienci widzą tą samą strukturę
- aby korzystać z CODY klient potrzebuje jedynie wiedzieć gdzie znaleźć korzeń (w przeciwieństwie do NFS, gdzie musiał mieć aktualną listę serwerów z eksportowanymi katalogami).
- Serwery grupują pliki w wolumeny. Wolumen jest przeważnie mniejszy niż partycja i większy niż katalog.
Wolumen posiada korzeń i zawiera drzewo katalogów.
- wolumen może się pojawić w dowolnym miejscu /coda
- w momencie dodawania nowych serwerów (nie robimy tego sami) klient je zobaczy gdzieś wewnątrz tego drzewa
Struktura i działanie Systemu
Serwery - VSG/AVSG
- Dane wolumeny przechowywane są w pewnym podzbiorze wszystkich serwerów. Te serwery noszš nazwę VSG (Volume Storage Group) - grupy wolumenów pamięci.
- W damym momencie klient ma dostęp do podzbioru VSG - nazywanego AVSG (Available VSG).
Najczęściej AVSG < vsg , np. z powodu awarii jednego z serwerów czy braku połączenia
- CODA daje nam gwarancję aktualności, tzn dostarczenia najnowszej kopii danego pliku z grupy AVSG
- Jeśli grupa AVSG jest pusta, to dostajemy kopię pliku z pamięci podręcznej
Procesy Venus i Vice, obietnice zawiadomienia
- Coda składa się w zasadzie z 2 częsci: procesu Vice (na serwerze) i procesu Venus (na stacji roboczej)
- Venus odpowiada za pamięć podręczną po stronie klienta. Na żądanie sprawdza czy nie ma danego pliku w cache'u dysku, oraz kontaktuje się z serwerami w celu sciągnięcia kopii pliku
- Vice działa po stronie serwera. Dostarczając procesowi Venus kopię pliku dołącza do niej tzw. obietnicę zawiadomienia (callback promise) - gwarancję że zostanie powiadomiony o modyfikacji pliku. Obietnice zawiadomienia mogš być w stanie "ważny" lub "unieważniony".
- Gdy Vice zajmuje się aktualizacją danego pliku, powiadamia o tym wszystkie procesy Venus mające ustawione
obietnice zawiadomienia na "ważne". Wysyła do nich stosowną informację wraz z poleceniem unieważnienia obietnicy zawiadomienia.
Wektor wersji
- Z każdym plikiem związany jest tzw. wektor wersji - CVV (Coda Version Vector),
używany przy aktualizacji plików na serwerach
- CVV = [n1,n2,..,nk], gdzie ni - licznik zmian związany z konkretnym serwerem z VSG, na którym trzymany jest wolumen z danym plikiem
- Dzięki temu wektorowi wiadomo która wersja pliku jest najbardziej aktualna i czy nie mamy konfliktów
- Załóżmy że zmodyfikowaliśmy jakiś plik. Proces Venus w chwili zamykania pliku wysyła do każdego serwera w grupie
AVSG komunikat uaktualniający (z bieżącym CVV i nowym plikiem)
- Proces Vice sprawdza CVV i jeśli nie jest on zgodny z jego CVV to zapamiętuje plik i odsyła potwierdzenie
- Na koniec Venus oblicza nowy CVV (zwiększając liczniki zmian dla serwerów, które odpowiedziały pozytywnie) i rozsyła go do członków grupy AVSG.
- Minimalizuje to obciążenie serwera - rozprowadzeniem zmian zajmuje się klient
Obsługa dostępu do pliku przez klienta
- Czytaj jeden, zapisuj wiele (read-one, write-all) - czytamy z jednego serwera, aktualizacja w calym AVSG
- Interesuje nas jakiś konkretny plik. Jeśli jest kopia w pamieci podręcznej wraz z "obietnicą zawiadomienia" - to klient czyta plik z pamieci podręcznej
- Brak obietnicy zawiadomienia: klient sprawdza czy jest to najnowsza kopia (porównuje z kopiami na innych
serwerach AVSG analizując CVV)
- Jeśli nie jest, to ściąga najnowszą wersję (i informuje odpowiednich członków AVSG
o przeterminowaniu ich kopii)
- Jeśli w ogole nie ma pliku - klient wskazuje serwer z AVSG (losowo lub w/g wydajności) i
zamawia na nim kopię atrybutów pliku (CVV) wraz z zawartością
Usuwanie niespójności/Konflikty
- Niespójność występuje wtedy gdy mamy różne wersje pliku na różnych serwerach VSG
- Automatyczne usuwanie niespójności: wtedy, gdy elementy CVV na jednym serwerze
są większe bądź równe od odpowiedznich elementów wektora na innych serwerach
(np. [3,3,2] i [2,2,2] - OK)
- W przeciwnym wypadku trzeba ręcznie rozwiązać konfilkt (są programy wspomagające)
- Przykład:
- Mamy plik, serwery - {S1,S2,S3} oraz klientów - {C1,C2}, gdzie VSG dla tego pliku to {S1,S2,S3},
AVSG dla C1 to {S1,S2}, AVSG dla C2 - {S3}
- pocztątkowo CVV dla pliku na wszystkich serwerach wynosi [1,1,1]
- Klient C1 modyfikuje plik, Venus wysyła zmiany do serwerów ze swojego AVSG {S1,S2},
na których postają nowe wersje pliku wraz z wektorem [2, 2, 1]
- Klient C2 modyfikuje plik, Venus wysyła zmiany do jedynego serwera ze swojego AVSG - S1,
na którym postaje nowa wersja pliku wraz z wektorem [1, 1, 2]
- Klient C2 sprawdza, czy niedostępni członkowie grupy VSG stali się osiągalni.
Okazuje się że tak, więc zmienia swoją grupę AVSG na {S1, S2, S3} i zamawia CVV od wszystkich członków grupy.
Dostaje wektory : [2,2,1],[2,2,1],[1,1,2]. Stwierdza, że wektory są sprzeczne i że usunięcie
konfliktu wymaga ręcznej interwencji klienta.
- Gdyby C2 nie modyfikował pliku, to po zmianie grupy AVSG dla C2 wektory CVV w serwerach S1 i S2
dominowałyby nad wektorem z serwera S3 i wersja pliku z S1 lub S2 zastąpiła by tą w S3.
Inne cechy CODY
Operacje odłączone
- Jeśli z jakiegoś powodu nie mamy dostępu do żadnego serwera (padła sieć, odłączyliśmy notebooka),
a chcemy korzystać z plików z CODY, wykonujemy "operację odłączoną"
- Pracujemy na kopiach lokalnych. Po ponownym podłączeniu nastąpi reintegracja danych.
- Problem pojawia się gdy nie mamy potrzebnych danych w pamięci podręcznej
- Krótkie odłączenia : przed brakami infomacji może chronić polityka LRU - usuwanie
z pamięci podręcznej plików używanych najdawniej
- Długie odłączenia : możemy ustalić priorytety w/g których proces Venus ma organizować
pamięć podręczną (określić pliki i katalogi priorytetowe) - instnieją do tego odpowiednie narzędzia.
Między innymi dostępne jest narzędzie umożliwiające użytkownikowi ujmowanie ciągów działań na plikach w nawiasy. Proces Venus odnotowuje odwołania do plików w takim ciągu i na tej podstawie nadaje plikom priorytety.
- Reintegracja danych po ponownym podłączenu wykonuje się następująco: ("ponowne scalanie" - reintegration process):
- Dla każdego zmienionego pliku z pamięci podręcznej (lub usuniętego) Venus wykonuje aktualizację
w odpowiednich grupach AVSG
- W razie niezgodności kopia z pamięci podręcznej zostaje czasowo zapamiętana na serwerze w wolumenie uzupełniającym, a użytkownik otrzymuje stosowną informację.
Spójność pamięci podręcznej
- Kopie plików pozostające w pamięci podręczej można uważać za aktualne
tylko pod warunkiem okresowego przywracania im ważności (w przypadku operacji odłączonych - po ponownym połączeniu)
- U każdego klienta Venus musi wykrywać w czasie najdalej T sekund wystąpienie takich zdarzeń jak powiększenie/zmiejszenie AVSG czy unieważnienie obietnicy zawiadomienia. Żeby to osiągnąć co T sekund rozsyła komunikat do wszystkich serwerów z VSG, które utrzymują pliki przechowywane w pamięci podręcznej.
- Jeśli otrzyma odpowiedź od serwera poprzednio niedostępnego, to powiększa skład grupy AVSG i unieważnia
obietnice zawiadomień plików pochodzacych z tego serwera
- Jeśli nie otrzyma odpowiedzi, to zmniejsza grupę AVSG
- W odpowiedzi na komunikat próbny Venus-owi dostaje CVV wolumenu (zestawienie CVV dla wszystkich
plików wolumenu). Jeśli Venus wykryje jakąkolwiek niezgodność - to znaczy że jacyś członkowie AVSG mają pewne pliki w wersjach nieaktualnych. Venus przyjmuje wówczas założenie pesymistyczne i unieważnia obietnice zawiadomień wszystkich plików, które pochodzą z tego wolumenu.
Linki
Autor: Wiktor Lisowicz
|
|
